home *** CD-ROM | disk | FTP | other *** search
/ Floppyshop 2 / Floppyshop - 2.zip / Floppyshop - 2.iso / art&graf.ix / art-5625 / gif2fli / gif2flie.doc < prev    next >
Text File  |  1995-10-07  |  12KB  |  254 lines
  1.                                Gif to FLI
  2.                                ==========
  3.                                 
  4.                             MdB Software 1995
  5.  
  6. ===========================================================================
  7.  
  8. Copyright (C) 1993 by Klaus Ehrenfried. 
  9.  
  10. Permission to use, copy, modify, and distribute this software
  11. is hereby granted, provided that the above copyright notice appears 
  12. in all copies and that the software is available to all free of charge. 
  13. The author disclaims all warranties with regard to this software, 
  14. including all implied warranties of merchant-ability and fitness. 
  15. The code is simply distributed as it is.
  16.  
  17. ===========================================================================
  18.  
  19. About GIF2FLI:
  20. --------------
  21. GIF2FLI is FREEWARE!!!!!
  22. The program `GI2FLI' allows to generate FLI-animations  
  23. from series of single gif images.
  24.  
  25. Content:
  26. --------
  27. GIF2FLI.PRG (compiled with GCC 68000)
  28. GIF2FLI.DOC (french doc)
  29. GIF2FLIE.doc (english doc)
  30. IMAGES.LST (exemple of a *.LST file)
  31.  
  32. Usage:
  33. ------
  34.  
  35. GIF2FLI [options] list.lst anim.fli
  36.  
  37. Parameters:
  38.  
  39. "list.lst" is the name of a file which contains line by line a list of names 
  40. of image files which are merged together in the given order. DON'T USE 
  41. BLANK LINES PLEASE!!!  
  42. "anim.fli" is simply the name of the generated animation file. 
  43.  
  44. Options overview:
  45.  
  46.     -b*    :    border color = *
  47.     -D    :    double buffering
  48.     -m*    :    map-file name = *
  49.     -O    :    generate FLI with old format
  50.     -ox*    :    horizontal origin = *
  51.     -oy*    :    vertical origin = *
  52.     -rx*    :    horizontal resolution = *
  53.     -rx*    :    vertical resolution = *
  54.     -s*    :    animation speed = *
  55.  
  56. Options details:
  57.  
  58. -b* (border color):
  59.   In regions where no input data is available, because the input image 
  60.   doesn't cover the hole display area of the animation, 
  61.   the pixel value is set to the given value. By default zero is used. 
  62.   See also the "-ox" option. 
  63.  
  64. -D (double buffer):
  65.   By default the generated FLI chunks only hold the update information 
  66.   with respect to the last frame. If the "-D" option is given, the FLI 
  67.   chunks additionally provide the update information with respect 
  68.   to the frame before the last. In both cases the FLI animations 
  69.   work with standard players. The additional update information is useful 
  70.   for players which use double buffer technique (see remark below). 
  71.   If you have not such a player this option is useless.
  72.  
  73. -m* (map file):
  74.   The color table of the given image file is used for all images
  75.   in the animation. The original color table in the animated images is 
  76.   ignored. The map file itself becomes not part of the animation. 
  77.   Only its color table is used. This option is useful in many 
  78.   circumstances. E.g: it is possible to change the colors in the 
  79.   hole animation simply by manipulating the table of one file. 
  80.  
  81. -O (old format)
  82.   An old format FLI with Magic Number 0xAF11 is generated. Instead of the
  83.   DELTA_CHUNKS (7) the old LC_CHUNKS (12) are used and COLOR_CHUNKS (11) 
  84.   instead of COLOR_256_CHUNKS (4). Some older players cannot handle newer FLI 
  85.   animations with the Magic Number 0xAF12. This option allows to generate 
  86.   FLIs for this players. When the "-O" option is given the default 
  87.   resolution is set to 320x200. Otherwise 640x480 is used. 
  88.  
  89.   Note: Often the new format FLIs are called `FLC'-files but I use the name
  90.   `FLI' for both the new and the old standard.
  91.  
  92. -ox* (horizontal position):
  93.   By this option the horizontal position of the left border of the 
  94.   input images in the display area of the animation is controlled. The value 
  95.   gives the number of pixels from the left border of the displayed area to
  96.   the left border of the image. By default the input images are centered 
  97.   in the display area. If the width of an input image is less than the 
  98.   chosen resolution, borders are inserted on both sides of the image 
  99.   symmetrically. The border area is filled with the pixel value given 
  100.   by the "-b" option. If the width of an input image has a higher value 
  101.   than the chosen resolution, an equal amount of pixels is cut off from 
  102.   both sides of the input image. Thus, when the size of the animated 
  103.   images varies, the left border of the images is at different locations 
  104.   in the display. If the "-ox" option is given, the automatic centering 
  105.   is disabled and the left border of the input image is kept fixed at the 
  106.   given horizontal position. This can be used to place small input images 
  107.   at a certain position in the display, or to animate only a certain section 
  108.   of larger input images. 
  109.  
  110. -oy* (vertical position):
  111.   Same as "-ox" but for the vertical position. The value gives the number 
  112.   of pixels between the upper border of the display area and the upper 
  113.   border of the input image.
  114.   Note: With "-ox" and "-oy" also negative values are allowed. Then parts 
  115.   of the input images are outside the display area.
  116.  
  117. -rx* (horizontal resolution):
  118.   With this option the horizontal resolution can be modified. The value can 
  119.   range from 10 to 1280. If an odd value is given, 1 is added automatically. 
  120.   I do not know if all players (especially the players which only handle 
  121.   old format FLIs) can deal with all resolutions. In principle the VGA
  122.   resolution 320x200 should always work. For players which can play the 
  123.   FLIs with Magic Number 0xAF12 at least 640x480 should work also. When 
  124.   strange numbers are used nothing is guaranteed. 
  125.  
  126. -ry* (vertical resolution)
  127.   Like "-rx*" but for the vertical direction. In contrast to "-rx*" here
  128.   also odd numbers are accepted. Maximum value is 1024.
  129.  
  130. -s* (speed):
  131.   In the header of the FLI file a default value for the animation speed
  132.   is stored (Actually not directly the speed but the delay time between 
  133.   two frames is stored).
  134.   This default value is used by some players if no other speed
  135.   is set at playing time. The meaning of the value depends on the format 
  136.   of the FLIs. For old format FLIs the value gives the number of video 
  137.   ticks between two frames. If "-s*" is omitted a default of 5 is used. 
  138.   For new format FLIs the delay between two frames is given in 1/1000 
  139.   seconds rather than video ticks. In this case a default of 72/1000 
  140.   seconds is used. This results in approximately 15 frames per seconds. 
  141.   In both cases a higher value reduces the speed. 
  142.  
  143. ===========================================================================
  144.  
  145. Examples:
  146.  
  147.   Pathological example to explain the use of "-ox", "-oy", "-rx" and "-ry": 
  148.   -------------------------------------------------------------------------
  149.   We have a series of images with different resolutions. We want a 36x10 
  150.   resolution for the FLI animation. We want that the images are not 
  151.   automatically centered, but that the upper-left corner of the images is 
  152.   located at the position (6,2) in display area. The origin (0,0) of the 
  153.   coordinate system of the display area is located in the upper-left corner.
  154.   The name of the list file is "example.lst" and the name of the generated 
  155.   FLI file is "example.fli". We type:
  156.  
  157.       GIF2FLI -rx36 -ry10 -ox6 -oy2 example.lst example.fli
  158.  
  159.   The following figure shows the resulting location for an input image with 
  160.   9x5 pixels: 
  161.  
  162.       0123456
  163.       |< - >|
  164.  
  165.       ------------------------------------  --0
  166.       |                                  |    1
  167.       |     ---------                    |  --2
  168.       |     | input |                    |
  169.       |     | image |                    |
  170.       |     | 9x5   |                    |
  171.       |     ---------                    |
  172.       |                                  |
  173.       |                                  |
  174.       ------------------------------------
  175.             ( Display area 36x10 pixel )
  176.  
  177.  
  178.   More reasonable example to explain the use of "-ox", "-oy", "-rx" and "-ry": 
  179.   ---------------------------------------------------------------------------
  180.   We have a series of 768x512 images produced by someone else or by a 
  181.   commercial software. We want to animate these images, but we want that 
  182.   the top 20 lines of each image are cut off, because there occurs something 
  183.   disturbing (advertisement or so). 
  184.   Again the name of the list file is "example.lst" and the name of the 
  185.   generated FLI file is "example.fli". We type:
  186.  
  187.       GIF2FLI -rx768 -ry492 -oy-20 example.lst example.fli
  188.  
  189.   Note 1): 492 = 512 - 20.
  190.   Note 2): Also negative values are allowed with the options "-ox" and "-oy".
  191.            Of course, if a negative value is given the upper-left corner 
  192.            of the images is outside the display area.
  193.  
  194.   Example to explain the use of "-m": 
  195.   -----------------------------------
  196.   We have a series of images and all have the same color table. But the 
  197.   used colors are ugly and it is much work to change all color tables. 
  198.   Then we generate a special image (using a color-table editor) 
  199.   which has a better color table. We assume that the name of this file is 
  200.   "nice_colors.gif".
  201.   Again the name of the list file is "example.lst" and the name of the 
  202.   generated FLI file is "example.fli". We type:
  203.  
  204.       GIF2FLI -mnice_colors.gif example.lst example.fli
  205.  
  206. ===========================================================================
  207.  
  208. Remarks about double buffering (PC players only):
  209. [About the sense of the "-D" option]
  210.  
  211. One special feature of `GIF2FLI' is that the program can generate 
  212. animations for players which use double buffering. The advantage of 
  213. players which use double buffering is that they allow a smooth 
  214. and undisturbed display even in cases where almost all pixels are 
  215. changing from one frame to the next. Most players write directly to 
  216. the visible part of the video memory. The FLI-file holds the update
  217. information for the next frame. The player waits until the beginning 
  218. of the vertical blank period of the video signal (this is the time 
  219. in which the electron beam in the monitor moves from the bottom to 
  220. the top) and then it starts to update the video memory. If too much 
  221. pixels have to be updated or the access to the video memory it too 
  222. slow (ISA bus and higher resolution ...) one gets disturbances in the 
  223. display. The reason for this is that an image is shortly visible on 
  224. the screen which has a part at the top already updated to the next 
  225. frame but the remainder at the bottom still shows the information from the 
  226. previous frame. Only if the player writes faster to the video 
  227. memory than the video chip reads this memory one gets 
  228. an undisturbed animation. But this can only be archived by very fast 
  229. graphic boards (50 MHz local bus and low resolution) or by animations where 
  230. not more than a certain amount of new pixels has to be updated 
  231. between the frames. 
  232. Double buffering simply overcomes these restrictions by using a 
  233. second buffer and writing to an invisible part of the video memory. 
  234. When the update of one buffer is complete the player switches the 
  235. display to the ready buffer and starts to process the next frame in 
  236. the other -- now invisible -- buffer. 
  237. But in this case the player needs the update information with 
  238. respect to the frame which previously was located in the same 
  239. buffer. And this frame is not the last one, which was processed in 
  240. exactly the other buffer, but the frame before the last. 
  241.  
  242.  
  243. In order to contact me :
  244. ------------------------
  245.  
  246. Chaussy Laurent
  247. 50 rue du bout d'en haut 
  248. 77570 Mondreville
  249. FRANCE
  250.  
  251. Email: chaussy@ibm580.ensicaen.ismra.fr
  252.  
  253.  
  254. Have fun with GIF2FLI !